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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://www.etsi.org/legal/home.htm ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 



Introduction 



The present document describes interoperability and compatibility tests for ITU-T Recommendation H.323 [5] entities 
concerning the different TIPHON scenarios. It is not intended to provide an exhaustive testing of all facets of 
ITU-T Recommendation H.323 [5] and SCN operation. Specific configurations were chosen to provide coverage of the 
more common commercial deployments. 

The test cases specified in this test plan must be performed on many different platforms. Therefore, specific details on 
how to perform each test are not included, only instructions on what information must be exchanged are included. 
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1 Scope 

The present document defines the interoperability test specifications for the following scenarios: 

• PC to PC; 

• PC to Phone; 

• Phone to PC; 

• Phone to Phone using IP; 

• PC to PC using the SCN. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[I] ETSI TS 101 319: "Telecommunications and Internet Protocol Harmonization Over Networks 
(TIPHON); Signalling for basic calls from a H.323 terminal to a terminal in a Switched-Circuit 
Network (SCN)". 

[2] ETSI TS 101 804 (all parts): "Telecommunications and Internet protocol Harmonization Over 

Networks (TIPHON) Release 3; Release PICS". 

[3] ETSI TS 101 329-5: "Telecommunications and Internet protocol Harmonization Over Networks 

(TIPHON) Release 3; Technology Compliance Specification; Part 5: Quality Of Service (QoS) 
measurement methodologies". 

[4] ETSI TS 101 890 (all parts): "Telecommunications and Internet protocol Harmonization Over 

Networks (TIPHON) Release 3; Release PICS". 

[5] ITU-T Recommendation H.323 (1999): "Packet-based multimedia communications systems" (See 

note). 

[6] ITU-T Recommendation H. 225.0 (1999): "Call signalling protocols and media stream 

packetization for packet-based multimedia communication systems". 

[7] ITU-T Recommendation E. 164: "The international public telecommunication numbering plan". 

[8] ITU-T Recommendation G.711: "Pulse code modulation (PCM) of voice frequencies". 

[9] ITU-T Recommendation G. 723.1 (1996): "Dual rate speech coder for multimedia communications 

transmitting at 5,3 and 6,3 kit/sec". 

[10] ITU-T Recommendation G.729: "Coding of speech at 8 kbit/s using conjugate structure algebraic- 

code-excited linear-prediction (CS-ACELP)". 

[II] ITU-T Recommendation H.245 (1999): "Control protocol for multimedia communication" (See 
note). 

NOTE: The Interoperability Testing can be performed for any version of H.323, but this specification is 
applicable for the versions defined in clause 6.1 of the present document. 
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Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

A Audio 

ACF Admissions Confirm 

ARJ Admissions Reject 

ARQ Admissions Request 

D Data 

DRQ Disengage Request 

GSM Global System for Mobile communications 

IE Information Element 

IP Internet Protocol 

ISDN Intergrated Service Digital Networks 

LCF Location Confirm 

LRJ Location Reject 

LRQ Location Request 

(P)NNI (Private) Network to Network Interface 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

SCN Switched Circuit Networks 

UNI User-Network Interface 



Test Strategy 



The purpose of interoperability testing is to test compatibility with other products, which use the same TIPHON 
specifications. 

Interoperability testing should be performed after a vendor has completed product and system testing with its own test 
procedures and/or using the TIPHON Conformance Test standards as defined in TS 101 804 (all parts) [2] and 
TS 101 890 (all parts) [4]. 

When performing interoperability testing for Signalling, the vendor's test procedures should include those contained in 
the present document. 

Speech Quality Testing is considered to be a separate activity and is not a part of interoperability testing. TIPHON 
Speech Quality Testing procedures are defined in TS 101 329-5 [3], 



Overview 



For set up of equipment, the present document uses a number of basic configurations. These are used to run a certain 
number of tests. 

The basic configurations are: 

1) Terminal to Terminal; 

2) Telephone to Terminal; 

3) Telephone to Telephone using IP as a transit Network; 

4) Terminal to Terminal using SCN as a transit Network. 

Using these test configurations a number of different tests are performed. For example a call first from the Telephone to 
the Terminal and then the other way around or using different codex. 

These tests can include a variety of special features like FastConnect, or QoS. 

The number of Gatekeepers involved in these configurations depends on the actual executed test. 
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All the call flows shown in the tables are an example flows that should be followed if possible. In some cases not all the 
described messages occur. 



Prerequisites 



6.1 IP related 

The following prerequisites are taken from TIPHON specifications: 

• ITU-T Recommendation H.323 [5] (version 3, 1999) and TS 101 319 [1] shall be used; 

• ITU-T Recommendation H. 225.0 [6] (version 3, 1999) Fast Connect shall be used for all calls; 

• ITU-T Recommendation H.245 [11] (version 6, 1999) Tunnelling shall be used whenever H.245 messages are 
exchanged; 

• Gatekeeper Routed Signalling is mandatory; 

• H.323 Terminals shall register to the Gatekeeper using an ITU-T Recommendation E.164 [7] alias only; 

• Gateways shall register to the Gatekeeper using Prefixes only; 

• Endpoints shall support the keep Alive procedure as specified in clauses 6.2.2 and 7.4.2 of 
ITU-T Recommendation H.323 [5]; 

• When Fast Connect procedure is used, the SETUP Message shall include the fastStart Parameter, and the fast 
parameter shall be returned in exactly one message up to and including the CONNECT Message. 

6.2 SCN related 

To identify the different types of SCN interfaces the following shall be considered: 

• If the SCN interface is an UNI interface, the gateway can play either the "role" of the user or of the network side. 

• If the SCN interface is an (P)NNI interface, the gateway (or two gateways connected by the IP) can offer two 
types of services in principle: 

transparent transfer of SCN Signalling across IP connections; 

signalling interworking between SCN and IP "transit nodes". 

• (P)NNIs are located between Originating, Transit and Terminating Network nodes. 
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Parameter for each test 



There are some extra parameters that can be selected for each test: 



7.1 



Audio Codec 



As TIPHON is not only focussing on the call establishment but also on the Media stream, the audio Codec should be an 
extra parameter that should vary from test to test: 

Here is a list of all Codec that are defined in ETSI TIPHON: 

• ITU-T Recommendation G.7 1 1 [8] ; 

• ITU-T Recommendation G.723 . 1 [9] ; 

• ITU-T Recommendation G.729 [10]; 

• GSM Full Rate; 

• GSM Half Rate. 

Which Codec is selected should be specified prior to the test. 

7.2 Number of intermediate Gatekeepers 

All tests can be executed with one or more Gatekeepers. The Number of Gatekeepers is just another parameter for these 

tests. 

The description has to be extended accordingly, if more than 2 Gatekeepers are involved. 

If only one Gatekeeper is participating in a scenario, simply mark the not relevant lines of the table with n.a. in the 
succeeded column and simply ignore them. 



8 Configurations 



8.1 



Terminal to Terminal 



TA1 
ip 



1 



|"o"| I oooooo I I oo I 



Gatekeeper A 



ip 

(RTP/RTCP) 



IP 



Tbi 

IP 

-■El 



OOOOOO DO 



Gatekeeper B 



NOTE: Gatekeeper B is only present in specific test cases. 

Figure 1 : Terminal to Terminal 
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All tests can be executed with one or more Gatekeepers. The Number of Gatekeepers is just another parameter for these 

tests. 

Table 1 : Terminal to Terminal 



Direction 


Description 


Test Flow 


Extra feature 


Comment 


A1 -»B1 


Successful call 


8.1.1 


Fast connect 


TIPHON Scenario 


B1 -»A1 


Successful call 


8.1.1 


Fast connect 


TIPHON Scenario 


A1 -»B1 


Successful call 


8.1.3 


Fast connect 
fallback 


TIPHON Scenario 


B1 -»A1 


Successful call 


8.1.3 


Fast connect 
fallback 


TIPHON Scenario 


A1 -»D 


Basic unsuccessful call 


8.1.2 




TIPHON Scenario 


B1 -»D 


Basic unsuccessful call 


8.1.2 




TIPHON Scenario 



8.1 .1 Successful call from a H.323 Terminal to another H.323 Terminal 

This test verifies the TIPHON Scenario-0 service where the Originating Terminal and the Terminating Terminal are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship. 

Table 2: Successful call from a H.323 Terminal to another H.323 Terminal 



No. 


Action 


Succeeded 


1 


Both Terminal A1 and the Terminal B1 shall register with their respective Gatekeeper(s). 




2 


Terminal A1 initiates a call using an E.164 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B (see note). 




5 


Gatekeeper B returns LCF(see note). 




6 


Gatekeeper A returns ACF. 




7 


Terminal A1 sends SETUP its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B(see note). 




9 


Gatekeeper B forwards SETUP to Terminal B1 . 




10 


Terminating Terminal B1 performs ARQ/ACF sequence. 




11 


Terminal B1 sends an ALERT Message back. 




12 


The User at Terminal A1 should be informed that the other Terminal is alerting. 




13 


After Terminal B1 has accepted the call, the CONNECT message should travel back to the 
originating Terminal A1 . 




14 


Media is exchanged and Media connection is evaluated. 




15 


Terminal A1 terminates the call_and 

sends a RELEASE COMPLETE and a DRQ to its Gatekeeper. 




16 


The Gatekeeper(s) forward(s) the RELEASE COMPLETE to the Terminal B1 . 




17 


The User at Terminal B1 should be informed that the remote peer terminated the call. 




18 


The Terminal B1 should send the DRQ to its Gatekeeper. 





NOTE: Only present if this test is run with two Gatekeepers. 



8.1 .2 Unsuccessful call from H.323 Terminal to another H.323 Terminal 

This test verifies the TIPHON Scenario-0 service where the Originating Terminal and the Terminating Terminal should 
be registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship, but the connection 
fails as the Terminating Terminal is not registered. 
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Table 3: Unsuccessful call from H.323 Terminal to another H.323 Terminal 



No. 


Action 


Succeeded 


1 


Both Terminal A1 and the Terminal B1 should register with their respective Gatekeeper(s). 




2 


Terminal A1 initiates a call using a E.164 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B (see note). 




5 


Gatekeeper B returns LRJ (see note). 




6 


Gatekeeper A returns ARJ. 




7 


The user should be informed that the call failed indicating the cause. 





NOTE: Only present if this test is run with two Gatekeepers. 



If there are three Gatekeepers involved, the procedure should be extended accordingly. 

8.1 .3 Fast Connect Fallback to H.245 tunnelling 

This test verifies the support of fallback for the Fast Connect Procedure. 

The calling party shall include the fast Connect parameter in the setup message and set the H245 Tunnelling to TRUE. 
The called party shall not include the fastStart IE in any message but set the H245Tunneling to TRUE. As a result, the 
call has to be established using an H. 225.0 tunnel for the H.245 connection. 

The high-level call flow is described in clause 8.1.1. 



8.2 Terminal to Telephone 



Terminal A1 
ip 



ip 

"(RTP/RTCP)" 



dm 



SCN 



Oi 



Gateway B1 



Telephone 



ip 



IM 



^ 



Gatekeeper A 



ip- 



-m 



Gatekeeper B 



NOTE: Gatekeeper B is only present in specific test cases. 

Figure 2: Terminal-to-Telephone 

All tests can be executed with one or more Gatekeepers. The number of Gatekeepers is just another parameter for these 

tests. 

Table 4: Terminal to Telephone 



Direction 


Description 


Test Flow 


Extra feature 


Comment 


A1 -> Tel 


Successful call 


8.2.1 


Fast connect 


TIPHON Scenario 1 


Tel -» A1 


Successful call 


8.2.2 


Fast connect 


TIPHON Scenario 2 


A1 -> Tel 


Successful call 


8.2.7 


Fast connect 
fallback 


TIPHON Scenario 1 


Tel -» A1 


Successful call 


8.2.7 


Fast connect 
fallback 


TIPHON Scenario 2 


A1 ->D 


Basic unsuccessful call 


8.2.3 




TIPHON Scenario 1 


A1 -> Tel x 


Unsuccessful call with 
voice after disconnect 


8.2.4 




TIPHON Scenario 1 


A1 -> Tel x 


Unsuccessful call with 
voice before connect 


8.2.5 




TIPHON Scenario 1 


A1 ->D 


Basic unsuccessful call 


8.2.6 




TIPHON Scenario 1 
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8.2.1 Successful call from a H.323 Terminal to a Telephone 

This test verifies the TIPHON Scenario- 1 service where the Originating Terminal and the Terminating Gateway are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship. 

Table 5: Successful call from a H.323 Terminal to a Telephone 



No. 


Action 


succeeded 


1 


Both Terminal A1 and the Gateway B1 shall register with their respective Gatekeeper(s). 




2 


Terminal A1 initiates a call using a E.164 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B (see note). 




5 


Gatekeeper B returns LCF (see note). 




6 


Gatekeeper A returns ACF. 




7 


Terminal A1 sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B (see note). 




9 


Gatekeeper B forwards SETUP to Gateway B. 




10 


Terminating Gateway B performs ARQ/ACF sequence. 




11 


Gateway B initiates call establishment to SCN. 




12 


After the ALERT Message was received on the SCN side, it should be forwarded to the Terminal. 




13 


The User at the Terminal should be informed that the Telephone is ringing. 




14 


After the Telephone was picked up, the connect message should be forwarded from the Gateway to 
the Terminal and Media should be present immediately. 




15 


Media is exchanged and Media connection is evaluated. 




16 


Terminal A1 terminates the call and 

sends a RELEASE COMPLETE and a DRQ to its Gatekeeper 




17 


The Gatekeeper(s) forward(s) the RELEASE COMPLETE to the Gateway. 




18 


The Gateway initiates a call disestablishment to the SCN. 




19 


The User at the Telephone should hear appropriate tones. 




20 


The Gateways should send the DRQ to its Gatekeeper, after all resources associated with this call 
were released. 





NOTE: Only present if this test is run with two Gatekeepers. 



If there are three Gatekeepers involved, the procedure should be extended accordingly. 
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8.2.2 Successful call from a Telephone to a H.323 Terminal 

This test verifies the TIPHON Scenario-2 service where the Originating Gateway and the Terminating Terminal are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship. 

Table 6: Successful call from a Telephone to a H.323 Terminal 



No. 


Action 


succeeded 


1 


Both Terminal A1 and the Gateway B1 shall register with their respective Gatekeeper(s). 




2 


Telephone should dial a number to reach Terminal A1 
this can be done using one or two stage dialling. 




3 


Gateway sends ARQ to its Gatekeeper. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B (see note). 




5 


Gatekeeper B returns LCF (see note). 




6 


Gatekeeper A returns ACF. 




7 


Gateway sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B (see note). 




9 


Gatekeeper B forwards SETUP to Terminal. 




10 


Terminal performs ARQ/ACF sequence. 




11 


Terminal sends ALERT message back. 




12 


The Telephone should be informed that the Terminal is alerted and the user should hear 
appropriate tones. 




13 


After the User of the Terminal has answered the call, a CONNECT message should be forwarded 
to the Telephone and Media should be present immediately. 




14 


Media is exchanged and Media connection is evaluated. 




15 


The Telephone should release the call. 




16 


The Gateway should send a RELEASE_COMPLETE to its Gatekeeper and 
proceed to disestablish the call on the SCN side. 




17 


The Gatekeeper(s) forward(s) the RELEASE COMPLETE to the Terminal. 




18 


The User is informed that the call was terminated by the remote peer and 
the Terminal should send a DRQ to its Gatekeeper. 




19 


The Gateways should send the DRQ to its Gatekeeper, after all resources associated with this call 
were released. 





NOTE: Only present if this test is run with two Gatekeepers. 



If there are three Gatekeepers involved, the procedure should be extended accordingly. 

8.2.3 Unsuccessful Call from a Terminal to an "unknown SCN Number" 

This test verifies the TIPHON Scenario- 1 service where the Originating Terminal and the Terminating Gateway are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship, but the connection fails 
as the Number can not be terminated in the SCN. 

Table 7: Unsuccessful Call from a Terminal to an "unknown SCN Number" 



No. 


Action 


succeeded 


1 


Terminal A1 shall register with its respective Gatekeeper. 




2 


Terminal A1 initiates a call using a E.164 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B (see note). 




5 


Gatekeeper B returns LRJ, indicating an unknown number (see note). 




6 


Gatekeeper A returns ARJ. 




7 


The user should be informed that the call failed indicating the cause. 





NOTE: Only present if this test is run with two Gatekeepers. 



If there are three Gatekeepers involved, the procedure should be extended accordingly. 
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8.2.4 Unsuccessful call with voice after DISCONNECT 

This test verifies the ability to transfer data after a DISCONNECT message was received (on the SCN side) using 
TIPHON Scenario- 1 service where the Originating Terminal and the Terminating Gateway are registered with the same 
Gatekeeper or the Gatekeepers have a trusted relationship. 

NOTE: The in-band information generated by the announcement machine is sent during the release of the call. 
Table 8: Unsuccessful call with voice after DISCONNECT 



No. 


Action 


succeeded 


1 


Both Terminal A1 and the Gateway B1 shall register with their respective Gatekeeper(s). 




2 


Terminal A1 initiates a call using a E.164 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B (see note). 




5 


Gatekeeper B returns LCF (see note). 




6 


Gatekeeper A returns ACF. 




7 


Terminal A1 sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B (see note). 




9 


Gatekeeper B forwards SETUP to Gateway B. 




10 


Terminating Gateway B performs ARQ/ACF sequence. 




11 


Gateway B initiates call establishment to SCN. 




12 


The SCN answers using a DISCONNECT Message, indicating that there is a voice message 
present in the media channel. 




13 


Gateway B sends a PROGRESS Message to its Gatekeeper (including fast connect option). 




14 


The PROGRESS Message is forwarded to the Terminal and Media is switched on. 




15 


The Message should be presented to the User. 




16 


Terminal A1 terminates the call and 

sends a RELEASE COMPLETE and a DRQ to its Gatekeeper. 




17 


The Gatekeeper(s) forward(s) the RELEASE COMPLETE to the Gateway. 




18 


The Gateway initiates a call disestablishment to the SCN. 




19 


The Gateway should send the DRQ to its Gatekeeper, after all resources associated with this call 
were released.. 





NOTE: Only present if this test is run with two Gatekeepers. 



If there are three Gatekeepers involved, the procedure should be extended accordingly. 

The only difference between "8.2.4 Unsuccessful call with voice after disconnect" and "8.2.5 Unsuccessful call with 
voice before connect" is the behaviour of the SCN, sending a PROGRESS or a DISCONNECT Message. 
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8.2.5 Unsuccessful call with voice before connect 

This test verifies the ability to transfer data before CONNECT message was received using TIPHON Scenario- 1 service 
where the Originating Terminal and the Terminating Gateway are registered the same Gatekeepers or the Gatekeepers 
have a trusted relationship. 

NOTE: The in-band information generated by the announcement machine is sent before the active phase of the 
call i.e. SCN will never generate a CONNECT message. 

Table 9: Unsuccessful call with voice before connect 



No. 


Action 


succeeded 


1 


Both Terminal A1 and the Gateway B1 shall register with their respective Gatekeeper(s). 




2 


Terminal A1 initiates a call using a E.164 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B (see note). 




5 


Gatekeeper B returns LCF (see note). 




6 


Gatekeeper A returns ACF. 




7 


Terminal A1 sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B (see note). 




9 


Gatekeeper B forwards SETUP to Gateway B. 




10 


Terminating Gateway B performs ARQ/ACF sequence. 




11 


Gateway B initiates call establishment to SCN. 




12 


The SCN answers using a PROGRESS Message, indicating that there is a voice message present 
in the media channel. 




13 


Gateway B forwards PROGRESS Message to its Gatekeeper (including fast connect option). 




14 


The PROGRESS Message is forwarded to the Terminal and Media is switched on. 




15 


The Message should be presented to the User. 




16 


Terminal A1 terminates the call and sends a RELEASE COMPLETE and a DRQ to its Gatekeeper. 




17 


The Gatekeeper(s) forward(s) the RELEASE COMPLETE to the Gateway. 




18 


The Gateway initiates a call disestablishment to the SCN. 




19 


The Gateway should send the DRQ to its Gatekeeper, after all resources associated with this call 
were released. 





NOTE: Only present if this test is run with two Gatekeepers. 



If there are three Gatekeepers involved, the procedure should be extended accordingly. 

The only difference between "8.2.4 Unsuccessful call with voice after disconnect" and "8.2.5 Unsuccessful call with 
voice before connect" is the behaviour of the SCN, sending a PROGRESS or a DISCONNECT Message. 

8.2.6 Unsuccessful Call from a Telephone to an "unknown IP Number" 

This test verifies the TIPHON Scenario-2 service where the Originating Gateway and the Terminating Terminal should 
be registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship, but the connection 
fails as the Terminating Terminal is not registered. 

Table 10: Unsuccessful Call from a Telephone to an "unknown IP Number" 



No. 


Action 


succeeded 


1 


Gateway B1 shall register with its respective Gatekeeper. 




2 


Telephone should dial a number to reach Terminal A1 
this can be done using one or two stage dialling. 




3 


Gateway B1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper B issues LRQ (uni/multicast) to Gatekeeper A (see note). 




5 


Gatekeeper A returns LRJ, indicating an unknown number (see note). 




6 


Gatekeeper B returns ARJ. 




7 


The user should be informed that this number is not available, by playing a busy tone or an 
announcement. 





NOTE: Only present if this test is run with two Gatekeepers. 



If there are three Gatekeepers involved, the procedure should be extended accordingly. 



ETSI 



15 



ETSI TS 101 335 V4.1.1 (2001-10) 



8.2.7 Fast Connect Fallback to H.245 tunnelling 

This test verifies the support of fallback for the Fast Connect Procedure. 

The calling party shall include the fastConnect parameter in the setup message and set the H245Tunneling to TRUE. 
The called party shall not include the fastStart IE in any message but set the H245Tunneling to TRUE. As a result, the 
call has to be established using an H. 225.0 tunnel for the H.245 connection. 

The high level call flow is described in 8.2.1 or 8.2.2. 

8.3 Telephone to Telephone using IP Network 



01 



Telephone 



SCN— ► 



Gateway A1 



ip 



[HI 



oooooo oo 



Gatekeeper A 



ip 

"(RTP/RTCP)" 



IP 



4 SCN ► 



Gateway B1 



"HMi 



iUMJ 



Gatekeeper B 



CI 



Telephone 



NOTE: Gatekeeper B is only present in specific test cases. 

Figure 3: Telephone-to-Telephone using IP Network 

All tests can be executed with one or more Gatekeepers. The Number of Gatekeepers is just another parameter for these 
tests. 

Table 11 : Telephone to Telephone using IP Network 



Direction 


Description 


Test Flow 


Extra feature 


Comment 


Tel A -» Tel B 


Successful call 


8.2.1 


Fast connect 


TIPHON Scenario 3 


Tel B -» Tel A 


Successful call 


8.3.1 


Fast connect 


TIPHON Scenario 3 


Tel A -» Tel B 


Successful call 


8.3.3 


Fast connect fallback 


TIPHON Scenario 3 


Tel B -» Tel A 


Successful call 


8.3.3 


Fast connect fallback 


TIPHON Scenario 3 


Tel A -» Tel B 


Basic unsuccessful 
call 


8.3.2 




TIPHON Scenario 3 


Tel B -» Tel A 


Basic unsuccessful 
call 


8.3.2 




TIPHON Scenario 3 
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8.3.1 Successful call from a Telephone to a Telephone using IP Network 

This test verifies the TIPHON Scenario-3 service where the Originating Gateway and the Terminating Gateway are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship. 

Table 12: Successful call from a Telephone to a Telephone using IP Network 



No. 


Action 


succeeded 


1 


Both Gateways A1 and B1 shall register with their respective Gatekeeper(s). 




2 


The Telephone calls Gateway A1 and initiates a call to Telephone B. 




3 


Gateway A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B (see note). 




5 


Gatekeeper B returns LCF (see note). 




6 


Gatekeeper A returns ACF. 




7 


Gateway A1 sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B (see note). 




9 


Gatekeeper B forwards SETUP to Gateway B. 




10 


Terminating Gateway B performs ARQ/ACF sequence. 




11 


Gateway B initiates call establishment to SCN. 




12 


After the ALERT Message was received on the Gateway B SCN, it should be forwarded to the 
Gateway A1 . 




13 


The User at the Telephone A should be informed that Telephone B is ringing. 




14 


After Telephone B was picked up, the CONNECT message should be forwarded from the Gateway 
to the Gateway and Media should be present immediately. 




15 


Media is exchanged and Media connection is evaluated. 




16 


Telephone A terminates the call. 




17 


Gateway A1 send a RELEASE COMPLETE to its Gatekeeper. 




18 


The Gatekeeper(s) forward(s) the RELEASE COMPLETE to Gateway. B 




19 


The Gateway B initiates a call disestablishment to the SCN B. 




20 


The User at the Telephone B should hear appropriate tones. 




21 


The Gateways should send the DRQ to its Gatekeeper, after all resources associated with this call 
were released. 





NOTE: Only present if this test is run with two Gatekeepers. 



If there are three Gatekeepers involved, the procedure should be extended accordingly. 
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8.3.2 Unsuccessful call from a Telephone to a Telephone using IP 
Network 

This test verifies the TIPHON Scenario-3 service where the Originating Gateway and the Terminating Gateway are 
registered with the same Gatekeeper or where the two Gatekeepers have a trusted relationship, but the connection fails 
as the Number can not be terminated in the SCN. 

Table 13: Unsuccessful call from a Telephone to a Telephone using IP Network 



No. 


Action 


succeeded 


1 


Both Gateways A1 and B1 shall register with their respective Gatekeeper(s). 




2 


The Telephone calls Gateway A1 and initiates a call to a Telephone. 




3 


Gateway A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A issues LRQ (uni/multicast) to Gatekeeper B (see note). 




5 


Gatekeeper B returns LCF (see note). 




6 


Gatekeeper A returns ACF. 




7 


Gateway A1 sends SETUP to its Gatekeeper (including fast connect options). 




8 


Gatekeeper A forwards SETUP to Gatekeeper B (see note). 




9 


Gatekeeper B forwards SETUP to Gateway B. 




10 


Terminating Gateway B performs ARQ/ACF sequence. 




11 


Gateway B initiates call establishment to SCN. 




12 


The call could not be terminated in the SCN. 




13 


The User at the Telephone A should be informed that the call could not be completed. 




14 


After Telephone A terminates the call, a RELESASE COMPLETE should be sent to Gatekeeper A. 




15 


The Gatekeeper(s) forward(s) the RELEASE COMPLETE to Gateway B. 




16 


The Gateway B initiates a call disestablishment to the SCN B. 




17 


The Gateways should send the DRQ to its Gatekeeper, after all resources associated with this call 
were released. 





NOTE: Only present if this test is run with two Gatekeepers. 
If there are three Gatekeepers involved, the procedure should be extended accordingly. 

8.3.3 Fast Connect Fallback to H.245 tunnelling 

This test verifies the support of fallback for the Fast Connect Procedure. 

The calling party shall include the fastConnect parameter in the setup message and set the H.245 tunneling to TRUE. 
The called party shall not include the fastStart IE in any message but set the H.245 tunneling to TRUE. As a result, the 
call has to be established using an H. 225.0 tunnel for the H.245 connection. 

The high level call flow is described in clause 8.3.1 

8.4 Terminal to Terminal using SCN Network 




Gatekeeper A 



Gatekeeper B 



Figure 4: Terminal to Terminal using SCN Network 
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Table 14: Possible Tests 



Direction 


Description 


Test Flow 


Extra feature 


Comment 


A1 ->B1 


Successful call 


8.4.1 


Fast connect 


TIPHON Scenario 4 


B1 ->A1 


Successful call 


8.4.1 


Fast connect 


TIPHON Scenario 4 


A1 ->B1 


Successful call 


8.4.1 


H. 245 tunnelling 


TIPHON Scenario 4 


B1 ->A1 


Successful call 


8.4.1 


H. 245 tunnelling 


TIPHON Scenario 4 


A1 ->D 


Basic unsuccessful 
call 


8.4.2 




TIPHON Scenario 4 


B1 ->D 


Basic unsuccessful 
call 


8.4.2 




TIPHON Scenario 4 



8.4.1 Successful call from a H.323 Terminal to a H.323 Terminal using 
SCN Network 

This test verifies the TIPHON Scenario-4 service where the Originating Terminal and Gateway are registered to one 
Gatekeeper and the Terminating Gateway and Terminal are registered to another Gatekeeper. 

Table 15: Successful call from a H.323 Terminal to a H.323 Terminal using SCN Network 



No. 


Action 


succeeded 


1 


All Terminals and Gateways should register with their respective Gatekeepers. 




2 


Terminal A1 initiates a call using a E.164 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A 




4 


Gatekeeper A returns ACF. 




5 


Terminal sends setup to Gatekeeper A 




6 


Gatekeeper A forwards SETUP to Gateway A2. 




7 


Gateway A2 performs ARQ/ACF sequence. 




8 


Gateway A2 initiates an outgoing call to Gateway B1 . 




9 


Gateway B2 detects an incoming call and send an ARQ to Gatekeeper B. 




10 


Gatekeeper B responds with an ACF. 




11 


Gateway B2 sends SETUP to Gatekeeper B. 




12 


Gatekeeper(s) forward(s) SETUP to Terminal B1 . 




13 


Terminal B1 send ARQ to Gatekeeper B. 




14 


Gatekeeper B answers with ACF. 




15 


Terminal B1 accepts the call and sends an ALERT Message. 




16 


Terminal send ALERT message back. 




17 


The originating Terminal should be informed that the other side is alerted. 




18 


After the User of the Terminal has answered the call, a CONNECT message should be forwarded 
to the originating side, and Media should be present immediately. 




19 


Media is exchanged and Media connection is evaluated. 




20 


Terminal B1 sends a RELEASE COMPLETE and a DRQ to the Gatekeeper B. 




21 


The Gatekeeper B forwards this to the Gateway B2. 




22 


The Gateway B2 should terminate the SCN call to Gateway A1 . 




23 


Gateway A2 sends a RELEASE COMPLETE to the Gatekeeper A. 




24 


Gatekeeper A should inform the Terminal A1 that the call is released. 




25 


Terminal A1 should inform the user that the remote peer terminated the call and send a DRQ to the 
Gatekeeper. 




26 


The Gateway A2 and B2 should send a DRQ to their Gatekeepers, after all resources have been 
released. 





8.4.2 Unsuccessful call from a H.323 Terminal to a H.323 Terminal using 
SCN Network 

This test verifies the TIPHON Scenario-4 service where the Originating Terminal and Gateway are registered to one 
Gatekeeper and the Terminating Gateway and Terminal are registered to another Gatekeeper. The call can not be 
completed as the called Terminal is not registered with its Gatekeeper. 
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Table 16: Unsuccessful call from a H.323 Terminal to a H.323 Terminal using SCN Network 



No. 


Action 


succeeded 


1 


All Terminals and Gateways should register with their respective Gatekeepers. 




2 


Terminal A1 initiates a call using a E.164 address. 




3 


Terminal A1 sends ARQ to Gatekeeper A. 




4 


Gatekeeper A returns LCF. 




5 


Terminal A1 sends SETUP to Gatekeeper A 




6 


Gatekeeper A forwards SETUP to Gateway A2. 




7 


Gateway A2 performs ARQ/ACF sequence. 




8 


Gateway A2 initiates an outgoing call to Gateway B1 . 




9 


Gateway B2 detects an incoming call and send an ARQ to Gatekeeper B. 




10 


Gatekeeper B responds with an ARJ. 




11 


Gateway B2 disconnects SCN call providing the proper DISCONNECT CAUSE. 




12 


Gateway A2 sends RELEASE COMPLETE to Gatekeeper A including the CAUSE. 




13 


Gateway A2 forwards RELEASE COMPLETE to Terminal A1 including the CAUSE. 




14 


The User at Terminal 1 is informed that the called user is not reachable and the CAUSE is 
presented. 
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